The present invention relates to an apparatus and method for controlling requests for boot programs to a server computer system by a plurality of client computer systems in a remotely controlled boot environment. Specifically, the invention provides for a priority boot, a paced boot or a combination priority and paced boot enabled by a remotely controlled boot process.
A computer or computer system, when turned on, must be prepared for operation by loading an operating system. In the normal operation of a single computer system, when a user issues a boot command to the computer, the computer responds to the boot command by attempting to retrieve the operating system files from the computer systems memory. Configuration data files are also needed to configure the specific machine with the hardware parameters necessary for the specific hardware configuration. These files also contain information needed to initialize video adapters, printers, and peripherals associated with the particular machine. For example, the files would include CONFIG.SYS in the MS-DOS operating system, available from MICROSOFT Corporation.
Computers or computer systems can be connected in a network normally consisting of a client workstation, a server and a central network. In a system where the computer""s storage is maintained when the power is turned off, the operating system can be stored in the computer itself In a system where the computer has only storage that is lost when the power is turned off, the computer cannot retrieve the boot information from within the computer itself In that case, the client sends a request for the operating system files via the network to the server acting as a boot server. Even when the client workstation has non-volatile storage capability, it is advantageous to boot from the server because memory space is saved in the workstation computer. As operating system and application programs expand to provide new and greater capabilities, booting from a server can be highly advantageous.
Remote booting of a client workstation from a server is known in the art. U.S. Pat. No. 5,842,011 discloses a method for booting a local workstation from a server where the network is established by sending the operating system to the workstation when the power is turned on at the local workstation. The local workstation then boots from the transferred operating system which is now in its memory. U.S. Pat. No. 5,577,210 discloses a method for booting the local workstation where the operating system is transferred to the local workstation by the server in response to the first interruption produced by a terminal after it is turned on.
Several methods of remote booting exist in the marketplace. One is called Remote Initial Program Load (RIPL). RIPL is the process of loading an operating system onto a workstation from a remote location. The RIPL protocol was co-developed by 3Com, Microsoft, and IBM. It is used today with IBM OS/2 Warp Server, DEC Pathworks, and Windows NT. Two other commonly used Remote IPL protocols are a Novell NCP (NetWare Core Protocol), and BOOT-P, an IEEE standard, used with UNIX and TCP/IP networks.
RIPL is achieved using a combination of hardware and software. The requesting device, called the requester or workstation, starts up by asking the loading device to send it a bootstrap program. The loading device is another computer that has a hard disk and is called the RIPL server or file server. The RIPL server uses a loader program to send the bootstrap program to the workstation. Once the workstation receives the bootstrap program, it is then equipped to request an operating system, which in turn can request and use application programs. The software implementations differ between vendors, but theoretically, they all perform similar functions and go through a similar process. The client workstation requires a special Read Only Memory (ROM) installed on its (Local Area Network) LAN adapter or Network Interface Card (NIC). The special ROM is known generally as a remote boot ROM, but two specific examples of remote boot chips are the RIPL chip, which supports ANSI/IEEE standard 802.2, and the Preboot Execution Environment (PXE) chip, which is used in the Transmission Control Protocol/Internet Protocol (TCP/IP) environment.
While the process has many advantages for booting a computer that has volatile storage, such as a network computer, the computer is required to have a remote boot ROM on the LAN adapter or Network Interface Card (NIC). The remote boot ROM requirement does not allow any user interaction with the remote boot process. U.S. Pat. No. 6,463,530 discloses a remote boot process that does not require a remote boot ROM on the LAN adapter or NIC.
Existing boot manager configurations allow different partitions to be booted based on the user""s choice from a menu at machine start time. The selection criteria for the menu is hard coded on the local machine hard drive. Therefore, changes to the boot manager configuration must be done locally at the machine and normally require a reboot post configuration, a very tedious process in a large enterprise environment involving thousands of machines.
Therefore, a need exists for a remotely controlled boot manager which would allow the administrator to change the boot manager configuration remotely, from a server, and have the workstation pick up those changes every boot. Administrators could then configure items such as what to boot, timeout values, and defaults from a server rather than at the local machine. Thus, a need exists for an apparatus and method in a LAN/WAN environment for remote administration of workstation boot choices.
Workstations that boot across a network such as RIPL or PX)E can create a high demand on the boot server. This demand can over stress the boot server and flood the network causing congestion. A need exists for a way to stagger the booting of these workstations. In other words, a need exists for a method and apparatus to delay the booting of some workstations while others are allowed to boot in order to minimize the incident of peak loads, thus relieving the load on the boot servers and the network congestion.
The invention meeting the needs identified above is a Controlled Network Boot Process which provides an apparatus and method to allow a server in a LAN environment to control the boot requests from client machines to eliminate congestion on the network. Using the RIPL/PXE Emulation software, it is possible to control the workstations RIPL/PXE process. Just prior to sending out the RIPL Request or the start of the PXE process, the Controlled Network Boot Process (CNBP) would send a frame to a process, on another machine, responsible for monitoring and maintaining a staggered boot sequence. This xe2x80x9cserverxe2x80x9d sided process of the CNBP would be responsible for understanding how to maintain a staggered boot order and would respond to each workstation request appropriately. Additionally, the controlling server can display a menu to the user at the client machine informing the user of the status of the boot activity. The invention is enabled by the Remotely Controlled Boot (RCB) process which comprises a set of programs at the workstation which interacts with the BOOTCONTROL program at the server.
The RCB programs at the workstation allow a remote boot and interaction with the server sided process of the CNBP called BOOTCONTROL. Instructions from a Basic Input Output System (BIOS) ROM are executed to load a Boot Code Loader (BCL) from a nonvolatile, read/write memory, such as a diskette or hard disk. The BCL executes to load a Remote Control Program (RCP) from the diskette, and the RCP executes to load a message program, a protocol manager and/or device drivers from the diskette without loading an operating system. The message program and/or device drivers communicate with a program called BOOTCONTROL in the network server. The program will interface with an NDIS compliant Network Interface Card (NIC) to send out a discovery frame. The discovery frame will be intercepted by BOOTCONTROL installed on the servers which will be running and listening for the request. Once BOOTCONTROL intercepts the request it will send back the boot program or bootcontrol display information informing the client of the approximate time to boot. If the boot device is unavailable and a time-out value and prioritized list is supplied the process will continue to attempt to boot for the amount of time expressed by the value. If time-out expires the next bootable option is attempted. The process continues until a successful boot occurs.
Essentially, there are two programs to the CNBP process. On the client or workstation end, the RCB programs are used. The invention which meets the needs identified above is contained in the BOOTCONTROL program located on the servers that are available for providing boot programs to the client workstations. When the client seeks to boot and turns on the computer, the pre-boot environment will take control of the workstation and, in the case of the staggered boot, send out a frame to a server process to ask permission to continue to boot. The client side will then wait for a reply from the server process to allow it to continue.
The server sided process will listen for these client requests and will manage the traffic in allowing the order and sequence of workstations to boot. Two basic methods are employed. First, a priority boot is employed. Second, a paced boot is employed. A third, method may be employed which combines both the paced boot and the priority boot.
Priority boot requires a known state to be in place for the program to accomplish its end purpose. A known state is defined as a state in which all client stations are attempting to boot at the same time. For example, after a power loss, it is normal to anticipate that when the power is turned back on, most if not all of the client stations will attempt to boot and will make the attempt at the same time or very close to the same time. Given the definition of known state, i.e. all client machines attempting to boot, priorities can be established by the administrator based on customer selection. For example, in a bank branch, the administrator may designate that teller workstations are the highest priority and should be booted first so they can service the customers in line at the bank. The criteria to select a priority consists of a list of machines arranged in groups with a separation time between each group. For example:
Machine 1
Machine 2
Machine 3
120 second time period
Machine 4
Machine 5
Machine 6
120 second time period
Machine 7
120 second time period
In this example, Machine 1, 2, and 3 are booted first. 120 seconds later, Machines 4, 5 and 6 are booted. 120 seconds later Machine 7 is booted, and then 120 seconds later any other boot request is satisfied. Unlisted machines can also be booted allowing customers to only list those machines which are really important. Also, new machines that haven""t made it to the list will still be able to boot.
Paced boot contrasts with the priority boot in that paced boot works in an unknown state. Unknown state is defined as a state where the administrator does not know which machines will be started and at what times and therefore, cannot determine priorities. However, the administrator still wants to ensure that the server or servers do not become overburdened with an overload of boot request bunching at one point in time. The paced booting program will allow clients simply to boot in the order in which they are received at the server.
Paced boot requires only two parameters, time and the number of workstations. For example:
Time=120
Number=10
In this example, the server process will not allow more than 10 clients in a given time of 120 seconds. Because the administrator doesn""t know who or when users will turn on their machines in the xe2x80x9cunknownxe2x80x9d state the administrator can only pace the amount of clients attempting to boot.
A third option, is available in which the priority method and the paced method are combined. Such a combination allows the booting of the clients to be paced and can also allow prioritization if a client request comes in and is identified as a priority client. In such a case, that request would receive higher priority over any other requests during that period of time allowing that client to be booted before a client with lower priority or no priority at all.
The invention also allows for the server to send the client a message to let the client know what is happening. For example, the message sent from the server might tell the client how many minutes remain until the machines will be allowed to boot. For example, the message may say the following: xe2x80x9cPlease wait. Your machine will be booted in approximately three minutes.xe2x80x9d